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Security Services for the Registration Data Access Protocol (RDAP) 
Abstract 
The Registration Data Access Protocol (RDAP) provides "RESTful" web 
services to retrieve registration metadata from Domain Name and 
Regional Internet Registries. This document describes information 
security services, including access control, authentication, 
authorization, availability, data confidentiality, and data integrity 
for RDAP. 
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1. Introduction 


The Registration Data Access Protocol (RDAP) is specified in multiple 
documents, including "Registration Data Access Protocol (RDAP) Query 
Format" [RFC7482], "JSON Responses for the Registration Data Access 
Protocol (RDAP)" [RFC7483], and "HTTP Usage in the Registration Data 
Access Protocol (RDAP)" [RFC7480]. 


One goal of RDAP is to provide security services that do not exist in 
the WHOIS [RFC3912] protocol, including access control, 
authentication, authorization, availability, data confidentiality, 
and data integrity. This document describes how each of these 
services is achieved by RDAP using features that are available in 
other protocol layers. Additional or alternative mechanisms can be 
added in the future. Where applicable, informative references to 
requirements for a WHOIS replacement service [RFC3707] are noted. 


2. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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2.1. Acronyms and Abbreviations 
DNR: Domain Name Registry 
HTTP: Hypertext Transfer Protocol 
JSON: JavaScript Object Notation 
RDAP: Registration Data Access Protocol 
RIR: Regional Internet Registry 
TLS: Transport Layer Security 
3. Information Security Services and RDAP 


RDAP itself does not include native security services. Instead, RDAP 
relies on features that are available in other protocol layers to 
provide needed security services, including access control, 
authentication, authorization, availability, data confidentiality, 
and data integrity. A description of each of these security services 
can be found in "Internet Security Glossary, Version 2" [RFC4949]. 

No requirements have been identified for other security services. 


3.1. Access Control 


WHOIS does not include specific features to control access to 
registration information. As described in the following sections, 
RDAP includes features to identify, authenticate, and authorize 
clients, allowing server operators to control access to information 
based on a client’s identity and associated authorizations. 
Information returned to a client can be clearly marked with a status 
value (see Section 10.2.2 of [RFC7483]) that identifies the access 
granted to the client. 


3.2. Authentication 


This section describes security authentication mechanisms and the 
need for authorization policies to include them. It describes 
requirements for the implementations of clients and servers but does 
not dictate the policies of server operators. For example, a server 
operator with no policy regarding differentiated or tiered access to 
data will have no authorization mechanisms and will have no need for 
any type of authentication. A server operator with policies on 
differentiated access will have to construct an authorization scheme 
and will need to follow the specified authentication requirements. 
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WHOIS does not provide features to identify and authenticate clients. 
As noted in Section 3.1.4.2 of "Cross Registry Internet Service 
Protocol (CRISP) Requirements" [RFC3707], there is utility in 
allowing server operators to offer "varying degrees of access 
depending on policy and need." Clients have to be identified and 
authenticated to provide that utility. 


RDAP’s authentication framework needs to accommodate anonymous access 
as well as verification of identities using a range of authentication 
methods and credential services. To that end, RDAP clients and 
servers MUST implement the authentication framework specified in 
"Hypertext Transfer Protocol (HTTP/1.1): Authentication" [RFC7235]. 
The "basic" scheme can be used to send a client’s user name and 
password to a server in plaintext, base64-encoded form. The "digest" 
scheme can be used to authenticate a client without exposing the 
client’s plaintext password. If the "basic" scheme is used, HTTP 
over TLS [RFC2818] MUST be used to protect the client’s credentials 
from disclosure while in transit (see Section 3.5). 


Servers MUST support either Basic or Digest authentication; they are 
not required to support both. Clients MUST support both to 
interoperate with servers that support one or the other. Servers may 
provide a login page that triggers HTTP authentication. Clients 
should continue sending the HTTP authentication header once they 
receive an initial 401 (Unauthorized) response from the HTTP server 
as long as the scheme portion of the URL doesn’t change. 


The Transport Layer Security protocol [RFC5246] includes an optional 
feature to identify and authenticate clients who possess and present 
a valid X.509 digital certificate [RFC5280]. Support for this 
feature is OPTIONAL. 


RDAP does not impose any unique server authentication requirements. 
The server authentication provided by TLS fully addresses the needs 
of RDAP. In general, transports for RDAP must either provide a 
TLS-protected transport (e.g., HTTPS) or a mechanism that provides an 
equivalent level of server authentication. 


Work on HTTP authentication methods continues. RDAP is designed to 
be agile enough to support additional methods as they are defined. 


3.2.1. Federated Authentication 


The traditional client-server authentication model requires clients 
to maintain distinct credentials for every RDAP server. This 
situation can become unwieldy as the number of RDAP servers 
increases. Federated authentication mechanisms allow clients to use 
one credential to access multiple RDAP servers and reduce client 
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credential management complexity. RDAP MAY include a federated 
authentication mechanism that permits a client to access multiple 
RDAP servers in the same federation with one credential. 


Federated authentication mechanisms used by RDAP MUST be fully 
supported by HTTP. OAuth, OpenID, Security Assertion Markup Language 
(SAML), and mechanisms based on Certification Authority (CA) are all 
possible approaches to provide federated authentication. At the time 
of this document’s publication, negotiation or advertisement of 
federated authentication services is still an undefined mechanism by 
the noted federated authentication protocols. Developing this 
mechanism is beyond the scope of this document. 


The OAuth authorization framework [RFC6749] describes a method for 
users to access protected web resources without having to hand out 
their credentials. Instead, clients are issued access tokens by 
authorization servers with the permission of the resource owners. 
Using OAuth, multiple RDAP servers can form a federation, and the 
clients can access any server in the same federation by providing one 
credential registered in any server in that federation. The OAuth 
authorization framework is designed for use with HTTP and thus can be 
used with RDAP. 


OpenID [OpenID] is a decentralized single sign-on authentication 
system that allows users to log in at multiple web sites with one ID 
instead of having to create multiple unique accounts. An end user 
can freely choose which OpenID provider to use and can preserve their 
Identifier if they switch OpenID providers. 


Note that OAuth and OpenID do not consistently require data 
confidentiality services to protect interactions between providers 
and consumers. HTTP over TLS [RFC2818] can be used as needed to 
provide protection against man-in-the-middle attacks. 


SAML 2.0 [SAML] is an XML-based protocol that can be used to 
implement web-based authentication and authorization services, 
including single sign on. It uses security tokens containing 
assertions to exchange information about an end user between an 
identity provider and a service provider. 


The Transport Layer Security protocol describes the specification of 
a client certificate in Section 7.4.6 of [RFC5246]. Clients who 
possess and present a valid X.509 digital certificate, issued by a 
CA, could be identified and authenticated by a server who trusts the 
corresponding CA. A certificate authentication method can be used to 
achieve federated authentication in which multiple RDAP servers all 
trust the same CAs, and then any client with a certificate issued by 
a trusted CA can access any RDAP server in the federation. This 
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certificate-based mechanism is supported by HTTPS and can be used 
with RDAP. 


3.3. Authorization 


WHOIS does not provide services to grant different levels of access 
to clients based on a client’s authenticated identity. As noted in 
Section 3.1.4.2 of "Cross Registry Internet Service Protocol (CRISP) 
Requirements" [RFC3707], there is utility in allowing server 
operators to offer "varying degrees of access depending on policy and 
need." Access control decisions can be made once a client’s identity 
has been established and authenticated (see Section 3.2). 


Server operators MAY offer varying degrees of access depending on 
policy and need in conjunction with the authentication methods 
described in Section 3.2. If such varying degrees of access are 
supported, an RDAP server MUST provide granular access controls (that 
is, per registration data object) in order to implement authorization 
policies. Some examples: 


- Clients will be allowed access only to data for which they have a 
relationship. 


- Unauthenticated or anonymous access status may not yield any 
contact information. 


- Full access may be granted to a special group of authenticated 
clients. 


The type of access allowed by a server will most likely vary from one 
operator to the next. A description of the response privacy 
considerations associated with different levels of authorization can 
be found in Section 13 of [RFC7483]. 


3.4. Availability 


An RDAP service has to be available to be useful. There are no RDAP- 
unique requirements to provide availability, but as a general 
security consideration, a service operator needs to be aware of the 
issues associated with denial of service. A thorough reading of 
"Internet Denial-of-Service Considerations" [RFC4732] is advised. 


An RDAP service MAY use an HTTP throttling mechanism to limit the 
number of queries that a single client can send in a given period of 
time. If used, the server SHOULD return an HTTP 429 (Too Many 
Requests) response code as described in "Additional HTTP Status 
Codes" [RFC6585]. A client that receives a 429 response SHOULD 
decrease its query rate and honor the Retry-After header field if one 
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is present. Note that this is not a defense against 
denial-of-service attacks, since a malicious client could ignore the 
code and continue to send queries at a high rate. A server might use 
another response code if it did not wish to reveal to a client that 
rate limiting is the reason for the denial of a reply. 


3.5. Data Confidentiality 


WHOIS does not provide the ability to protect data from inadvertent 
disclosure while in transit. RDAP uses HTTP over TLS [RFC2818] to 
provide that protection by encrypting all traffic sent on the 
connection between client and server. HTTP over TLS MUST be used to 
protect all client-server exchanges unless operational constraints 
make it impossible to meet this requirement. It is also possible to 
encrypt discrete objects (such as command path segments and JSON- 
encoded response objects) at one endpoint, send them to the other 
endpoint via an unprotected transport protocol, and decrypt the 
object on receipt. Encryption algorithms as described in "Internet 
Security Glossary, Version 2" [RFC4949] are commonly used to provide 
data confidentiality at the object level. 


There are no current requirements for object-level data 
confidentiality using encryption. Support for this feature could be 
added to RDAP in the future. 


As noted in Section 3.2, the HTTP "basic" authentication scheme can 
be used to authenticate a client. When this scheme is used, HTTP 
over TLS MUST be used to protect the client’s credentials from 
disclosure while in transit. If the policy of the server operator 
requires encryption to protect client-server data exchanges (such as 
to protect non-public data that cannot be accessed without client 
identification and authentication), HTTP over TLS MUST be used to 
protect those exchanges. 


A description of privacy threats that can be addressed with 
confidentiality services can be found in Section 4. Section 10.2.2 
of [RFC7483] describes status values that can be used to describe 
operator actions used to protect response data from disclosure to 
unauthorized clients. 


3.6. Data Integrity 


WHOIS does not provide the ability to protect data from modification 
while in transit. Web services such as RDAP commonly use HTTP over 
TLS [RFC2818] to provide that protection by using a keyed Message 
Authentication Code (MAC) to detect modifications. It is also 
possible to sign discrete objects (such as command path segments and 
JSON-encoded response objects) at one endpoint, send them to the 
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other endpoint via a transport protocol, and validate the signature 
of the object on receipt. Digital signature algorithms as described 
in "Internet Security Glossary, Version 2" [RFC4949] are commonly 
used to provide data integrity at the object level. 


There are no current requirements for object-level data integrity 
using digital signatures. Support for this feature could be added to 
RDAP in the future. 


The most specific need for this service is to provide assurance that 
HTTP 30x redirection hints [RFC7231] and response elements returned 
from the server are not modified while in transit. If the policy of 
the server operator requires message integrity for client-server data 
exchanges, HTTP over TLS MUST be used to protect those exchanges. 


4. Privacy Threats Associated with Registration Data 


Registration data has historically included personal data about 
registrants. WHOIS services have historically made this information 
available to the public, creating a privacy risk by revealing the 
personal details of registrants. WHOIS services have not had the 
benefit of authentication or access control mechanisms to gate access 
to registration data. As a result of this, proxy and privacy 
services have arisen to shield the identities of registrants. 


The standardization of RDAP does not change or impact the data that 
operators may require to be collected from registrants, but it 
provides support for a number of mechanisms that may be used to 
mitigate privacy threats to registrants should operators choose to 
use them. 


RDAP includes mechanisms that can be used to authenticate clients, 
allowing servers to support tiered access based on local policy. 
This means that all registration data need no longer be public, and 
personal data or data that may be considered more sensitive can have 
its access restricted to specifically privileged clients. 


RDAP data structures allow servers to indicate via status values when 
data returned to clients has been made private, redacted, obscured, 


or registered by a proxy. "Private" means that the data is not 
designated for public consumption. "Redacted" means that some 
registration data fields are not being made available. "Obscured" 


means that data has been altered for the purposes of not readily 
revealing the actual registration information. One option that 
operators have available to them to reduce privacy risks to 
registrants is to adopt policies that make use of these status values 
to restrict the registrant data shared with any or all clients 
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according to the sensitivity of the data, the privileges of the 
clients, or some other heuristics. 


RDAP uses the jCard [RFC7095] standard format for entity 
representation. Operators may find that many of the jCard fields are 
irrelevant for registry operation purposes or that they have no 
reason to collect information from registrants that would correspond 
to certain fields. Operators wishing to reduce privacy risks for 
registrants may restrict which information they collect and/or which 
fields they populate in responses. 


In addition to privacy risks to registrants, there are also potential 
privacy risks for those who query registration data. For example, 
the fact that a registry employee performs a particular query may 
reveal information about the employee’s activities that he or she 
would have preferred to keep private. RDAP supports the use of HTTP 
over TLS to provide privacy protection for those querying registrant 
data as well as registrants, unless operational constraints make it 
impossible to meet this requirement. 


5. Security Considerations 


One of the goals of RDAP is to provide security services that do not 
exist in the WHOIS protocol. This document describes the security 
services provided by RDAP and associated protocol layers, including 
authentication, authorization, availability, data confidentiality, 
and data integrity. Non-repudiation services were also considered 
and ultimately rejected due to a lack of requirements. There are, 
however, currently deployed WHOIS servers that can return signed 
responses that provide non-repudiation with proof of origin. RDAP 
might need to be extended to provide this service in the future. 


As an HTTP-based protocol, RDAP is susceptible to code injection 
attacks. Code injection refers to adding code into a computer system 
or program to alter the course of execution. There are many types of 
code injection, including SQL injection, dynamic variable or function 
injection, include-file injection, shell injection, and HTML-script 
injection, among others. Data confidentiality and integrity services 
provide a measure of defense against man-in-the-middle injection 
attacks, but vulnerabilities in both client- and server-side software 
make it possible for injection attacks to succeed. Consistently 
checking and validating server credentials can help detect 
man-in-the-middle attacks. 


As noted in Section 3.2.1, digital certificates can be used to 
implement federated authentication. There is a risk of too 
promiscuous, or even rogue, CAs being included in the list of 
acceptable CAs that the TLS server sends the client as part of the 
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TLS client-authentication handshake and lending the appearance of 
trust to certificates signed by those CAs. Periodic monitoring of 
the list of CAs that RDAP servers trust for client authentication can 
help reduce this risk. 


The Transport Layer Security protocol [RFC5246] includes a null 
cipher suite that does not encrypt data and thus does not provide 
data confidentiality. This option MUST NOT be used when data 
confidentiality services are needed. Additional considerations for 
secure use of TLS are described in [SECURE-TLS-DTLS]. 


Data integrity services are sometimes mistakenly associated with 
directory service operational policy requirements focused on data 
accuracy. "Accuracy" refers to the truthful association of data 
elements (such as names, addresses, and telephone numbers) in the 
context of a particular directory object (such as a domain name). 
Accuracy requirements are out of scope for this protocol. 


Additional security considerations are described in the 
specifications for HTTP [RFC7231], HTTP Basic and Digest access 
authentication [RFC7235], HTTP over TLS [RFC2818], and additional 
HTTP status codes [RFC6585]. Security considerations for federated 
authentication systems can be found in the OAuth [RFC6749] and OpenID 
[OpenID] specifications. 
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